As it is generally known, multi-factor authentication provides user identification based on the combination of at least two different components: i) something that the user possesses, and ii) something that the user knows. For example, something the user knows may be a personal identification number (PIN), while something that the user possesses may be a software or hardware based security token assigned to a user, that generates a current “token code” at fixed intervals using a built-in clock and a special key known as the “token seed”. The token seed is different for each security token, and accordingly is different for each user. A copy of the token seed must also be stored in a corresponding authentication server. In order to be authenticated through the authentication server, e.g. to gain access to a secure network resource from a user device, the user must provide, to the authentication server, the current token code generated using the token seed for the user's security token at the current time. The server authenticates the user at least in part by computing the current token code that the user's security token is supposed to be generating at that moment in time, using the server's copy of the unique token seed assigned to the user's security token, and comparing the current token code computed at the server to the token code received from the user system.
In one example, a token seed for a software security token located in a user device (e.g. in a user's mobile phone) may first be generated in the authentication server, and then transmitted to the user device using a secure transport mechanism. In another example, the user device and the authentication server may generate the token seed collaboratively, without having to exchange the token seed over the network, using a cryptographic token key initialization protocol such as RSA Laboratories' Cryptographic Token Key Initialization Protocol (CT-KIP), or the Dynamic Symmetric Key Provisioning Protocol (DSKPP) described in Request for Comments (RFC) 6063 of the Internet Engineering Task Force (IETF).
After the token seed is present in the user device with the security token, the user can authenticate to a secure network resource from the user device, e.g. by providing their username, and both i) the current token code being generated by the token at that moment, and ii) their secret personal identification number (PIN). The generated token code and the PIN provided by the user may be combined to form a one-time passcode that is transmitted with the user's username to the authentication server. The authentication server then authenticates the user based on the data received from the client, in significant part by computing the current token code that the user's token is supposed to be generating at that moment in time using the server's copy of the token seed, and then comparing the current token code value computed on the server to the token code value received from the user device. The authentication server may also verify a PIN received from the user device.
In order for a multi-factor authentication system that employs a security token to provide secure user identification, it is important that the token seed be protected from exposure to malicious parties. This consideration is highlighted when the token seed is stored on a user device such as a mobile phone, which has a significant risk of theft or loss.